Ich werde erst auf Deutsch versuchen, meinen eigenen Vortrag zu übersetzen ins Deutsche.

Wenn wir auf MetaC-Pen ein Modul anschauen, dann sehen wir da am Rand Informationen über Coverage.

Genauso wenn wir professionelle Software entwickeln, kann es sein, wir werden mit Anforderungen

konfrontiert, die mit Coverage zu tun haben.

Und was das Ganze soll und wie es geht, damit beschäftige ich jetzt dieser Vortrag.

Ich darf mich kurz vorstellen, ich bin Martin Becker, wie der Moritz schon angekündigt hat.

Ich komme aus Blaubeuren am Fuße der Schwäbischen Alb.

Ich verdiene im Moment sogar Geld mit Qualitätssicherung.

Studiert habe ich Mathematik und bin immer noch in meiner Freizeit Mathematiker.

Ich fahre gern Fahrrad, habe auch eins dabei.

Seit über 20 Jahren bin ich auf Pearl- und Raku-Events, wobei es streng genommen, dass heute mein erstes Raku-Event ist.

Ich schreibe auch Module, die man auf SIPEN finden kann.

Das Thema Testen ist nicht für jeden besonders spannend, zumindest bis jetzt.

Aber wir können uns Softwareentwicklung ohne Tests gar nicht vorstellen.

Das beginnt schon ganz am Anfang, in einer frühen Phase der Entwicklung.

Das hier ist ein klassisches Modell der Softwareentwicklung, wo man am Schluss die Abnahme macht.

Aber auch im agilen Ansatz kommt das genauso gut vor, nur sind da die Schritte kleiner.

Wir haben also in der frühen Phase Unit-Tests, Integration-Tests, die schauen, ob die Units zusammenpassen.

Systemtests, also funktionale Tests aus Sicht des Entwicklers und aus Sicht des Kunden.

Bei den Unit-Tests geht es darum, dass der Code, der geschrieben entwickelt wurde, tatsächlich auch läuft.

Dass die dokumentierte Programmier-Oberfläche auch tatsächlich benutzt wird und so sich verhält wie dokumentiert.

Wir schauen an eine kleine logische Einheit.

Das kann ein Modul sein oder ein kleiner Verband von Modulen.

Etwas, was man isolieren und isoliert testen kann.

Wir streben nach guter Überdeckung, worauf ich gleich noch eingehen werde.

Und zwar profitieren wir auch davon, wenn wir das ganz am Anfang schon tun.

Es gibt sogar Test-Driven-Development, wo man die Tests zuerst schreibt.

Auf jeden Fall möchten wir frühzeitig testen, denn je früher Veränderungen vorgenommen werden,

die beim Testen sich als notwendig erweisen, desto billiger ist es.

Unser Hilfsmittel-Coverage-Analysis zeigt uns, welche Teile des Codes tatsächlich von den Tests erfasst sind.

Lücken, die da aufscheinen, geben uns Ideen, was wir eben noch testen sollen.

Allerdings sagt dieses Hilfsmittel uns nicht, ob ein Test ein guter Test ist.

Oder wie er gestaltet werden muss, dass er tatsächlich etwas, was zu den Anforderungen passt, beweist.

Genauso gut muss man sagen, dass der Integrationstest da noch außen vor bleibt, wenn ich ein Modul isoliert betrachte.

Zusätzlich kann ich auch davon profitieren, dass wenn ich einfach versuche, gute Überdeckung zu erreichen und das nicht hinbekomme,

dass ich dann an meinem Code Stellen finde, wo ich zum Beispiel Totencode habe oder etwas auf die Art finde,

wenn es durch Tests nicht erreichbar ist, was auch nicht in meiner Architektur erreichbar war.

Also sowohl das direkte Ergebnis der Coverage hilft mir, als auch der Versuch Coverage zu vergrößern.

Da wo ich nicht hinkomme mit Tests, da ist offensichtlich noch etwas falsch im Code.

Und was die Qualitätssicherer besonders freut, Coverage-Analysis wirft auch Zahlen ab,

dass man Metriken erhält für bestimmte Qualitäten.

Wir sind im Whitebox-Testing, das heißt wir dürfen den Code sehen und zerpflücken.

Und das kann man auf verschiedene Arten tun.

Die verbreitetsten oder einfachsten, die auch von den meisten Tools unterstützt werden, schauen auf den Kontrollfluss eines Programms.

Wenn ich anschaue, welche Wege der Kontrollfluss durch meine Anwendung nehmen kann

und daran eben auch orientiere, was ich testen möchte.

Eine tiefer gehende Analyse wäre Datenfluss orientiert, wo man also genau ingeniert,

wie die Daten manipuliert werden und wie sie Einfluss nehmen auf den Kontrollfluss.

Also zum ersten, Kontrollfluss orientierte Analyse, welche Überdeckungen gibt es da?

Eine der einfachsten Metriken ist die Statement Coverage.